Data Persistent

---

Containers are ephemeral by design, once stopped any data written in the container will be erased. This is not a limitation of the container, more of a design goal. This is the idea of immutable infrastructure, we do not change things once system is running. For changes, we redeploy the whole new container. But the tradeoff is the dataset, generated by the app itself. If we redeploy the whole container the unique dataset inside the container will be lost.

The separation of concern suggest, we should not mix the data set with the application binaries. Docker gives us two big favors here,

• Data Volumes
• Special location outside the Union file system
• Under Dockers storage directory
• Docker sees and manages this as a local file/folder
• Bind Mounts
• Mount a host directory file/folder into docker container
• Processes outside the docker can modify this

Volumes and Bind Mounts are both outside the container, but Volumes are under docker engine.

According to the Docker doc,

Bind mounts have been around since the early days of Docker. Bind mounts have limited functionality compared to volumes. When you use a bind mount, a file or directory on the host machine is mounted into a container. The file or directory is referenced by its full or relative path on the host machine. By contrast, when you use a volume, a new directory is created within Docker’s storage directory on the host machine, and Docker manages that directory’s contents.